Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/696

Internet Message Format | 1994-08-27 | 4KB

Date: Sun, 3 Jul 1994 14:32:33 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: First Vote
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407031433.A7342-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Nolte:

)Timothy Miller:
)>You won't be able to get AES 4.1,
)Hmm, that's strange. My AES calls itself 4.1 while booting. Have I got an
)insane AES or was I simply able to get it?

Ah... my mistake... then you won't be able to get anything LATER than 4.1.


Another note... in the independant-cursor block paradigm, how about we
make the option for line-delete work for block delete when a block has
been selected?  This way, backspace and delete won't be bothered with.


Christian:

)The block paradigm _does_ make a difference for shortcut. The
)Macintosh/NeXT guidelines are designed for the big-cursor paradigm. When a
)cursor exists simultaneously with a block
)  - you need a "hide block" function
)  - delete/BS probably can't be used for deleting the block
)  - setting block start/end in the menu makes sense
)  - so does copy/move to cursor position
)
)In essence, additional shortcuts are needed that would better be used for
)something else in the big-cursor paradigm.
)Since we want to set standards for other things as well, we should better
)put the big-cursor paradigm in the standard now, since it's well
)established on the ATARI and in all other major GUI's. Those who still want
)to implement the other sort of blocks (damn, isn't there a good name for
)it? ) can make up their own shortcuts.
)There isn't even an established standard for the other sort of block. I
)occasionally have to use old programs that use this (GFABasic, TurboASS,
)Tempus), but everyone has a different set of shortcuts for the block, and
)none of them understands ^X/^C/^V.

I agree with this, and the extra shortcuts required are one of the
reasons I don't like the independant cursor paradigm.


Warwick:

)>) If the mouse is placed over an editable text field, the mouse MUST change
)>) to a TEXT CURSOR while the mouse is over it.  It must be changed back to
)>) its original form when moved away.
)>
)>This isn't an easy thing to do.  It requires constant tracking of the
)>mouse position.  Do you have an easy way to do this?
)
)Actually, you just need to use the rectangle area tracking events.
)Using just two rectangles, it is possible to track any number of
)rectangles.  It is not trivial to implement and maintain this though.
)For example, under X11 windows, this is part of the OS.

I know.  I've seen it implemented before, and it's NOT easy.  You have to
find the rectangles of all selectable, touchexit, or editable objects and
make a rectaandle that fits in the areas not covered by them when the
mouse is not over one of those objects.  When the mouse IS over one of
those, you put a rectangle for that object.

There was discussion of busy-waiting... well, SOMETHING has to busy wait,
whether it's your app with a timer or 1-pixel rectangle, or it's the OS
which is given only mouse coordinates.  When you use rectangles, the OS
has to check the position of the mouse against the rectangles for every
mouse movement.  I wouldn't think that would have a whole lot less
overhead than having your program track a 1-pixel rectangle.


)>I just realized that I don't know how to build an object tree from
)>scratch.  Hmmm.
)
)It's very very easy.  Just keep all the links correct.  The last child's
)ob_next points to its parent.  The very last object in the form has the
)LASTOBJECT bit set.

I know these, but I just have never tried to do it before, so I don't
quite know all that's involved.  I'll leave the resource editors to the
experts.